不知道為什麼總覺得這個題目有點硬，但是我想還是要說一下這一點。

很多人寫程式，對自己的未來有各種不同的設定，有些人只是當一份職業。

上班下班這樣，需求來，照表操課，照spec做事你給我什麼我出產什麼給你。也沒有不好，我們就是解決問題的人。

像其他職業一般，廚師餵飽客人，服務客戶，但是做的事情有沒有到位或是要求自己就是另外一種境界。

在我一開始進入這個行業的時候我還抓不清楚自己的定位，不過我想簡單的用我以前的職業在廚藝的領域來做一個比喻。

我把廚房工作分為三種層次，以應對不同的客群，因為是服務業所以很直接的會跟客戶相關。

首先是廚工，在這個階段，你有成功的產出，趕得上送餐的時間，有依照客戶的點餐需求做好兼顧安全與衛生。

那你作為這個階段算是合格了，你面對的是吃到飽的客群，或著說吃飽，吃粗飽的普羅大眾。

第二個階段是，你開始會注重味覺上的感受，會去思考搭配的問題，會想著怎樣對客人才是最好的。

你的客人對味覺和其他感官上的追求，也不同於以往，對細節更是要求講究。

在這個階段，時程，需求正確與否，都已經不是問題，你的顧客它們知道從你產出的服務，和飲食產品是有一定的價值。有sense的客戶知道你是物有所值偶有驚喜，這個階層我稱之為廚師對應的是饕客，有品味講究精細的功夫。

而再上一層呢? 這一層有點難定義，吃對他們已經昇華到另外一種層次，這群人吃的是感受，吃的文化，吃的是風雅。

可能它的菜色是要復原，袁枚的 隨園食單，或是戰國年間的菜色，或是金庸小說裡面菜譜。

對用膳的講究從時間，對象，地點，為了什麼樣的事情該吃怎樣的菜餚，還有怎樣食材，這群人是美食家。而在這階層

的廚藝工作者，卻沒有稱呼了，你要叫大師也好，廚神也罷，對他來說名號，頭銜都已經不再重要，重要的是他跟他的

客人，一起打造了一場從文化，到感受，甚至是歷史上的重現，他跟客戶基本上是一體的，彼此合作讓彼此的價值跟獲

利發揮到最大。

回到我們的題目來，很多人在很多場合常常會談到軟體設計師的價值，究竟他們值不值得這麼高薪? 業務單位，PM，

做的很辛苦，程式設計師只要動動手指的產出? infra 整天在機房佈線，架機器。 PG只有涼涼的坐在電腦前敲鍵盤

類似的比較，我想大家應該都遇過很多。很多時候兩岸三地對這份工作也有不同的自嘲式的稱呼。

碼農，工程宅，IT狗。我覺得平常的時候，大家開開玩笑自嘲一下難免，但是言語有其力量，聖經裡面有一句話是

唯獨舌頭，沒有人能制伏，是不止息的惡物，滿了害死人的毒氣-雅各書第三章第八節。

我很喜歡一部電影，是梅莉史翠普演的 柴契爾的傳記電影

裡面有一段台詞是這樣的

你知道嗎 這個時代最大的問題...

我們是被這樣的人們領導著...

他們注重感覺 多於思考和想法

思考和想法才能讓我感興趣

注意你所想的 因為它們會變成嘴裡的話

注意你所說的 因為它們會變成實際的行動

注意你的行為 因為它們會形成習慣

注意你的習慣 因為它們會形成你的人格

注意你的人格 因為它們會影響你的命運

我們想的是什麼 就會成為什麼樣的人

其實我想說的是，你有多尊重這份工作，這份工作就會給你帶來多少收穫。

那程式設計師談需求究竟我們可以做到怎樣的程度呢?

首先 除了做需求以外? 有沒有問題是要幫忙考慮的?

舉個例子來說，用戶或是 PM提出這個需求的時候，不管你有沒有參與會議，是不是你去談回來的。

當你發覺需求有問題，有疑問，甚至不安全，有漏洞。交易相關帳戶密碼，明文傳輸? 或是直接querystring 送出?

需求是這樣寫，照需求做，出包你可以推給PM，SA，SD，你主管，或是這包是老闆的包，他自己扛。

或著，你也可以去提出疑問，這塊這麼做會不會有風險?

第二個是很多時候User端的需求是一團迷霧或是天方夜譚，有可能實現，實現了會大紅，或是突破現有技術瓶頸。

你可以分辨哪些是無理的要求，還是那些是有可能我們一起來try try看?

如果你的PM是JOBS，你會不會跟他一起耗下去，打造出一個又一個大放異彩的產品，還是只是照著需求做，超過的

就跟他說不好意思會拉時程，這個技術上辦不到? 當然如果是一個CASE老闆跟你說要拿20萬做一個像GOOGLE的網站

拜託請你先洗他臉，然後再把他的資訊散布給所有的接案圈。

再來一點是 維護性 這點我覺得應該很多人會有體會吧

從需求規劃開始，技術的選用決定，文件的齊備性，像是會議記錄，有沒有圖說，我知道很多人很討厭寫註解。

但是起碼方法上面加一個描述不會很花時間吧?我們是工程師又不是通靈師，萬一前人已逝 我們豈不是要觀落陰?不要當艾倫，而且以API來說現在又有swagger寫一下不吃虧，不然產品上線半年後要改我覺得通常吃鱉的是自己。

還有就是GIT push 之前的註解沒有功能性的描述，沒有講說改了那些，不是大公司也沒有需求單號碼或是其他的電子公文也就算了。打開紀錄一看通通都是"調整" ,"adjust","fixed" 阿是調了什麼東西，還要讓別人blame去看或是差異比對，這樣用板控是要做辛酸的嘛? 抱歉好像有點離題。不過在維護面上，我覺得做到這些不難啊，開發期間在一開始溝通的時候就可以去要求了。

最後一點，我覺得還是回到時程，曾幾何時聽過一個笑話。某公司的女PM在廁所梳妝打扮穿上超短裙，小一個cup的

內衣跟襯衫，噴上香水，套上網襪，畫了全裝加眼線，新人小妹問她:amy 姊今天晚上有局嘛?

只見姐姐噘噘嘴唇笑笑回答說:沒有喔，我是要去 「縮．短．時．程」。

有些人可能已經是一個小主管了，或是在開發團體裡

算是主key，你可能比較資深，對程式的了解比別人好跟通透，這時候 As a team 我覺得應該是有義務跟責任去幫助團隊。

正如同我第二天說的，"球不是一人踢的"。估計時程很大一部分是在於對資源的安排跟掌控上，當你是一個小團隊或是SOLO一個功能，我覺得你只需要了解自己跟程式，和商業邏輯跟你的業態。

但是如果是一群人一起工作，我覺得理解跟掌握你整個團隊的情況，SWOT這些是很重要的。看看幻影旅團。

我有一個同事，在外商軟體公司工作跟實習過。

他說他最喜歡看的就是每年年初，各單位在搶資源的時候，不管是head count 還是其他經費跟大大小小的資源。

你可以說這樣是因為不了解自己手上的team 或著反過來說很了解，才會竭盡全力去爭取，畢竟傳統上還是認為資源多

人月神話可以衝破一切，再不行就敏一下啊，這個開發流程不行就換啊，素質不OK就找廠商國外工程師協力開發支援啊。

錢是達成很多目標啦 但是在開發上，我覺得不行。

所以話說從頭，程式設計師的自我修養，其實某方面會展現出我們身為一個程式設計師的價值。

從整理需求開始，就是展現我們的專業，和他人不同之處。

今天發文有點晚因為有跑去玩耍啦

但是堅持，才是重點。會想說談需求這塊跟演員 喔不是 程式設計師的自我修養。

是因為今天上班在聽歌的是list 突然跳出了閃電霹靂車的主題曲。

讓我想到有一集，風見因為雷射感測器上有一根頭髮，導致阿斯拉的轉向一值有問題跟他的技師僵持很久。

開發上的經驗也是如此，以前我也是個不修邊幅的人，總覺得這應該是份自由的工作。

但是，進入職場久了看見那些令人尊敬前輩的背影，這幾年就好像進藤光開始決定要好好下棋一樣的心情。

也因為有一段時間，對自己身為程式設計師本身上價值的迷茫，逃避，讓我開始思考我跟那些前輩的差異

在哪裡? 技術嘛? 眼界嘛? 還是對這份工作的態度。

這個答案留給大家了。

今天就先到這裡，明天開始我們來談談，剛進入職場菜鳥生涯吧。

補充一下對應三種層次的程式設計師，單純做需求，這個沒有什麼不好。

再來是你對變數名稱可能有要求，對結構上可能很在意有沒有遵循SOLID的準則。

再上去也是另外一個境界。